Automated Unit Test Improvement using Large Language Models at Meta
o3.icon
論文の概要（超要約）
Meta が社内で運用している TestGen-LLM は、LLM を使って 既存の Kotlin 単体テストを“改良” するツールです。
「生成したテストが本当に価値を足しているか」を自動で検証し、合格したものだけをエンジニアにプルリクとして提示します。
仕組み - Assured Offline LLMSE
1. 候補生成
2種類の社内 LLM（論文では LLM-1/LLM-2 と表記）に複数プロンプトを投げ、既存テストクラスに追加するテストケースを大量生成。
2. 3段フィルターで保証を付与
1. Builds → コンパイルを通るか
2. Passes → 5回連続で安定パス（フレーク防止）
3. Improves→ 命令網羅や分岐網羅が増えたか
合格したテストだけが“改善”とみなされ、ドキュメント付きの diff が自動作成される。
3. 人間レビュー
フィルターを通過した diff は通常のコードレビューに載り、最終承認だけ人間が行う。
導入・評価結果
社内ベンチマーク（Instagram Reels & Stories）
生成テストの 75 % がビルド合格、57 % が安定パス、25 % がカバレッジ増加
Test-a-thon①（Instagram, 2023-11）
17 diff 中 16 diff が本番導入。行カバレッジ中央値 +2.5 行／テスト。
Test-a-thon②（Instagram+Facebook, 2023-12）
適用したクラスの 11.5 % を改善。エンジニアが 73 % の提案を受入れ。
何が新しいのか
「生成」ではなく「改良」
既存テストに corner-case を追加するため、実プロダクトにマージされやすい。
LLM ハルシネーションを“工学的に”封じ込め
失敗・フレーク・カバレッジ不足を段階的に落とすことで保証付きコード生成を実現。
産業規模での採用報告
LLM 生成テストが大規模コードベース（Instagram/Facebook）に本番導入された初の公開事例と主張。
技術・運用上の教訓
テスト oracle が無い領域では「失敗したら捨てる」戦略が有効
バグ検出よりもリグレッション防止を優先し、初回失敗テストは全て破棄。
フレーク排除は必須
5 回連続パスの簡易チェックでも効果大。CI 安定性を崩さず導入できた。
LLM & プロンプトは“アンサンブル”で
同一 LLM でも温度・システムプロンプト差分を並列実行し、多様な候補を確保。
カバレッジメトリクスを DevEx に翻訳
diff に自動で「何行増えたか」「未カバー分岐を取ったか」を添付するとレビュー速度が向上。
限界と今後の課題
Oracle 不在領域の網羅拡大
現状は「パスする＝正しい」と仮定。仕様ベースアサーション生成などが今後のテーマ。
より深いセマンティック保証
カバレッジ以外にミューテーションスコアやプロパティベーステストを組み込みたい。
他言語・モノレポ統合
Kotlin(Android) 以外のサービス層や C++ など多言語環境への適用検証が未着手。
ざっくり感想
「LLM にテストを書かせると壊れる」という先入観に対し、“保証付きパイプライン”をはさめば実務投入できる──という実証が最大の貢献。
特に Build→Pass→Improve の 3 段フィルターは、小規模プロジェクトでも応用しやすい設計パターンです。
関連